WebAssembly Specification
Release 1.0 (Draft, last updated Jan 23, 2018)
1. Introduction
1.1. Introduction
WebAssembly (abbreviated Wasm [1]) is a safe, portable, low-level code format designed for efficient execution and compact representation. Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.
WebAssembly is an open standard developed by a W3C Community Group that includes representatives of all major browser vendors.
This document describes version 1.0 of the core WebAssembly standard. It is intended that it will be superseded by new incremental releases with additional features in the future.
1.1.1. Design Goals
The design goals of WebAssembly are the following:
-
Fast, safe, and portable semantics:
- Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware.
- Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches.
- Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally.
- Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike.
- Language-independent: does not privilege any particular language, programming model, or object model.
- Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments.
- Open: programs can interoperate with their environment in a simple and universal manner.
-
Efficient and portable representation:
- Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats.
- Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately.
- Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation.
- Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen.
- Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks.
- Portable: makes no architectural assumptions that are not broadly supported across modern hardware.
WebAssembly code is also intended to be easy to inspect and debug, especially in environments like web browsers, but such features are beyond the scope of this specification.
| [1] | A contraction of “WebAssembly”, not an acronym, hence not using all-caps. |
| [2] | No program can break WebAssembly’s memory model. Of course, it cannot guarantee that an unsafe language compiling to WebAssembly does not corrupt its own memory layout, e.g. inside WebAssembly’s linear memory. |
1.1.2. Scope
At its core, WebAssembly is a virtual instruction set architecture (virtual ISA). As such, it has many use cases and can be embedded in many different environments. To encompass their variety and enable maximum reuse, the WebAssembly specification is split and layered into several documents.
This document is concerned with the core ISA layer of WebAssembly. It defines the instruction set, binary encoding, validation, and execution semantics, as well as a textual representation. It does not, however, define how WebAssembly programs can interact with a specific environment they execute in, nor how they are invoked from such an environment.
Instead, this specification is complemented by additional documents defining interfaces to specific embedding environments such as the Web. These will each define a WebAssembly application programming interface (API) suitable for a given environment.
1.1.3. Dependencies
WebAssembly depends on two existing standards:
- IEEE 754-2008, for the representation of floating-point data and the semantics of respective numeric operations.
- Unicode, for the representation of import/export names and the text format.
However, to make this specification self-contained, relevant aspects of the aforementioned standards are defined and formalized as part of this specification, such as the binary representation and rounding of floating-point values, and the value range and UTF-8 encoding of Unicode characters.
Note
The aforementioned standards are the authorative source of all respective definitions. Formalizations given in this specification are intended to match these definitions. Any discrepancy in the syntax or semantics described is to be considered an error.
1.2. Overview
1.2.1. Concepts
WebAssembly encodes a low-level, assembly-like programming language. This language is structured around the following concepts.
- Values
- WebAssembly provides only four basic value types. These are integers and IEEE 754-2008 numbers, each in 32 and 64 bit width. 32 bit integers also serve as Booleans and as memory addresses. The usual operations on these types are available, including the full matrix of conversions between them. There is no distinction between signed and unsigned integer types. Instead, integers are interpreted by respective operations as either unsigned or signed in two’s complement representation.
- Instructions
- The computational model of WebAssembly is based on a stack machine. Code consists of sequences of instructions that are executed in order. Instructions manipulate values on an implicit operand stack [1] and fall into two main categories. Simple instructions perform basic operations on data. They pop arguments from the operand stack and push results back to it. Control instructions alter control flow. Control flow is structured, meaning it is expressed with well-nested constructs such as blocks, loops, and conditionals. Branches can only target such constructs.
- Traps
- Under some conditions, certain instructions may produce a trap, which immediately aborts execution. Traps cannot be handled by WebAssembly code, but are reported to the outside environment, where they typically can be caught.
- Functions
- Code is organized into separate functions. Each function takes a sequence of values as parameters and returns a sequence of values as results. [2] Functions can call each other, including recursively, resulting in an implicit call stack that cannot be accessed directly. Functions may also declare mutable local variables that are usable as virtual registers.
- Tables
- A table is an array of opaque values of a particular element type. It allows programs to select such values indirectly through a dynamic index operand. Currently, the only available element type is an untyped function reference. Thereby, a program can call functions indirectly through a dynamic index into a table. For example, this allows emulating function pointers by way of table indices.
- Linear Memory
- A linear memory is a contiguous, mutable array of raw bytes. Such a memory is created with an initial size but can be grown dynamically. A program can load and store values from/to a linear memory at any byte address (including unaligned). Integer loads and stores can specify a storage size which is smaller than the size of the respective value type. A trap occurs if an access is not within the bounds of the current memory size.
- Modules
- A WebAssembly binary takes the form of a module that contains definitions for functions, tables, and linear memories, as well as mutable or immutable global variables. Definitions can also be imported, specifying a module/name pair and a suitable type. Each definition can optionally be exported under one or more names. In addition to definitions, modules can define initialization data for their memories or tables that takes the form of segments copied to given offsets. They can also define a start function that is automatically executed.
- Embedder
- A WebAssembly implementation will typically be embedded into a host environment. This environment defines how loading of modules is initiated, how imports are provided (including host-side definitions), and how exports can be accessed. However, the details of any particular embedding are beyond the scope of this specification, and will instead be provided by complementary, environment-specific API definitions.
| [1] | In practice, implementations need not maintain an actual operand stack. Instead, the stack can be viewed as a set of anonymous registers that are implicitly referenced by instructions. The type system ensures that the stack height, and thus any referenced register, is always known statically. |
| [2] | In the current version of WebAssembly, there may be at most one result value. |
1.2.2. Semantic Phases
Conceptually, the semantics of WebAssembly is divided into three phases. For each part of the language, the specification specifies each of them.
- Decoding
- WebAssembly modules are distributed in a binary format. Decoding processes that format and converts it into an internal representation of a module. In this specification, this representation is modelled by abstract syntax, but a real implementation could compile directly to machine code instead.
- Validation
- A decoded module has to be valid. Validation checks a number of well-formedness conditions to guarantee that the module is meaningful and safe. In particular, it performs type checking of functions and the instruction sequences in their bodies, ensuring for example that the operand stack is used consistently.
- Execution
-
Finally, a valid module can be executed. Execution can be further divided into two phases:
Instantiation. A module instance is the dynamic representation of a module, complete with its own state and execution stack. Instantiation executes the module body itself, given definitions for all its imports. It initializes globals, memories and tables and invokes the module’s start function if defined. It returns the instances of the module’s exports.
Invocation. Once instantiated, further WebAssembly computations can be initiated by invoking an exported function on a module instance. Given the required arguments, that executes the respective function and returns its results.
Instantiation and invocation are operations within the embedding environment.
2. Structure
2.1. Conventions
WebAssembly is a programming language that has multiple concrete representations (its binary format and the text format). Both map to a common structure. For conciseness, this structure is described in the form of an abstract syntax. All parts of this specification are defined in terms of this abstract syntax.
2.1.1. Grammar Notation
The following conventions are adopted in defining grammar rules for abstract syntax.
- Terminal symbols (atoms) are written in sans-serif font: .
- Nonterminal symbols are written in italic font:
. - is a sequence of class="">
<> . (This is a shortclass=""> used where <) . (This is a shorthand forclass=""> where < - class="">
<> where <- Productions are written
< - Some productions are augmented with side condclass="">
”, that provide a shorthand for a combinatorial expansion ofclass=""> <> - Nonterminal symbols are written in italic font:
2.1.2. Auxiliary Notation
When dealing with syntactic constructs the following notation is also used:
- denotes the empty sequence.
- denotes the leclass="">
. -th class=""> denotes the sub-sequenceclass=""> <>.denotes the same sclass=""> < is replaced with denotes the flat sequence fclass=""> . - denotes the leclass="">
Moreover, the following class="">
The following class=""> <
denotes the contents of the component ofclass="">
The update notation for sequences and records generalizes recursively to nested components accessed by “paths” :
- The meta variables range over integers.
- Numbers may be denoted by simple arithmetics, as in theclass="">
from sequences like , the latter is distinguished with parentheclass=""> - Numbers may be denoted by simple arithmetics, as in theclass="">
- The meta variable ranges over value types where clear from context.
- The notation
bit width of a value type. That is, < 2.3.2. Result Types
Result types classify the result of executing instructions or blocks, which is a sequence of values.
<In the current version of WebAssembly, at most one value is allowed as a result. However, this may be generalized to sequences of values in future versions.
- The notation
-
2.4. Instructions
WebAssembly code consists of sequences of instructions. Its computational model is based on a stack machine in that instructions manipulate values on an implicit operand stack, consuming (popping) argument values and producing (pushing) result values.
Note
In the current version of WebAssembly, at most one result value can be pushed by a single instruction. This restriction may be lifted in future versions.
In addition to dynamic operands from the stack, some instructions also have static immediate arguments, typically indices or type annotations, which are part of the instruction itself.
Some instructions are structured in that they bracket nested sequences of instructions.
The following sections group instructions into a number of different categories.
2.4.1. Numeric Instructions
Numeric instructions provide basic operations over numeric values of specific type. These operations closely match respective operations available in hardware.
value type. For each type, several subcategories can be distinguished: - Constants: return a static constant.
- Unary Operators: consume one operand and produce one result of the respective type.
- Binary Operators: consume two operands and produce one result of the respective type.
- Tests: consume one operand of the respective type and produce a Boolean integer result.
- Comparisons: consume two operands of the respective type and produce a Boolean integer result.
- Conversions: consume a value of one type and produce a result of another (the source type of the conversion is the one after the “”).
Some integer instructions come in two flavours, whereclass="">
distinguishes whether the operands are to beclass=""> interpreted as unsigned or signed integers. For the other integer instructions, the use of two’s complement for the signed interpretation means that they behave the same regardless of signedness. 2.4.1.1. Conventions
Occasionally, it is convenient to group operators together according to the following grammar shorthands:
<="syntax-instr-parametric">2.4.2. Parametric Instructions
Instructions in this group can operate on operands of any value type.
operator simply throws away class=""> operator selects one of itclass=""> < 2.4.3. Variable Instructions
Variable instructions are concerned with the access to local or global variables.
instruction is like but also returns its argclass=""> < 2.4.4. Memory Instructions
Instructions in this group are concerned with linear memory.
class="">and <>value types . They all take a memory immediate that contains an address offset< loads and stores can optionally specify a storage size that is smaller than the bit width of the respective value type. In the case of loads, a sign extension mode is then required to select appropriate behavclass=""> that is the zero-based index at which the memory is accessed. All values are read and written in little endian byte order. A trap results if any of the accessed memory bytes lies outside the address range implied by the memory’s current size.effective address Note
Future version of WebAssembly might provide memory instructions with 64 bit address ranges.
The instruction returns tclass="">
instruction grows memoryclass=""> page size. 2.4.5. Control Instructions
Instructions in this group affect the flow of control.
class="">class=""> instruction causes an unclass=""> <. The ,
< structured <>, terminated with, or separated by, or result type. Each structured control instruction introduces an implicit label. Labels are targets for branch instructions that reference them with label indices. Unlike with other index spaces, indexing of labels is relative by nesting depth, that is, label refers to the innermost structured control instruction enclosing the referring branch instruction, wclass="">
within the associated structured control instruction. This also implies that branches can only be directed outwards, “breaking” from the block of the control construct they target. The exact effect depends on that control construct. In case of or , reclass=""> . In case of backward jump class=""> < Note
This enforces structured control flow. Intuitively, a branch targeting a or
behaves like a performs an unconditional branch,class=""> performs a conditional branchclass=""> performs an indirect brancclass=""> instruction is a shortcut forclass=""> unwinds the operand stack up to the height where the targeted structured control instruction was entered. However, forward branches that target a control instruction with a non-empty result type consume matching operands first and push them back on the operand stack after unwinding, as a result for the terminated structured instruction. The instruction invokes another
. Since tables may contain function elements of heterogeneous type , the callee is dynamically checked againclass="">, consuming the necessary arguments from the stack and returning the result values of the call. The instruction calls a fclass=""> table function type indexed by the instruction’s immediate, and the call aborted with a trap if it does not match.Note
In the current version of WebAssembly, implicitly operates oclass="">
index . This restriction may be lifted in future versions. 2.4.6. Expressions
Function bodies, initialization values for globals, and offsets of element or data segments are given as expressions, which are sequences of instructions terminated by an marker.
restricts expressions to be constant, which limits the set of allowable instructions. 2.5. Modules
WebAssembly programs are organized into modules, which are the unit of deployment, loading, and compilation. A module collects definitions for types, functions, tables, memories, and globals. In addition, it can declare imports and exports and provide initialization logic in the form of data and element segments or a start function.
2.5.1. Indices
Definitions are referenced with zero-based indices. Each class of definition has its own index space, as distinguished by the following classes.
<, tables, memories and globals includes respective imports declared in the same module. The indices of these imports precede the indices of other definitions in the same index space.The index space for locals is only accessible inside a function and includes the parameters and local variables of that function, which precede the other locals.
Label indices reference structured control instructions inside an instruction sequence.
class=""> <2.5.2. Types
The component of a module defines a vector of class="">
function types .All function types used in a module must be defined in this component. They are referenced by type indices.
Note
Future versions of WebAssembly may add additional forms of type definitions.
2.5.3. Functions
The component of a module defines a vector of class="">
defined in the module. The parameters of the function are referenced through 0-based local indices in the function’s body.type The declare a vector of mutable local variablesclass=""> < internal" href="#syntax-localidx">local indices in the function’s body. The index of the first local is the smallest index not referencing a parameter.
The is an
result type .Functions are referenced through function indices, starting with the smallest index not referencing a function import.
2.5.4. Tables
The component of a module defines a vector ofclass=""> table type:
<#syntax-elemtype">element type. The size in theclass="">, if present, restricts the size to which it caclass=""> .element segments Tables are referenced through table indices, starting with the smallest index not referencing a table import. Most constructs implicitly reference table index .
<
In the current version of WebAssembly, at most one table may be defined or imported in a single module, and all constructs implicitly reference this table . This restriction may be lifted in future versions.
2.5.5. Memories
The component of a module defines a vector of
memory type: class="">size in the , if present, restricts the size to which it caclass=""> .page size Memories can be initialized through data segments.
Memories are referenced through memory indices, starting with the smallest index not referencing a memory import. Most constructs implicitly reference memory index .
<
In the current version of WebAssembly, at most one memory may be defined or imported in a single module, and all constructs implicitly reference this memory . This restriction may be lifted in future versions.
2.5.6. Globals
The component of a module defines a vector oclass="">
global type. Its also specifies whether a global is immutablclass=""> value given by a initializer expression. Globals are referenced through global indices, starting with the smallest index not referencing a global import.
2.5.7. Element Segments
The initial contents of a table is uninitialized. The component of a module defines a vector of
vector of elements. expression.Note
In the current version of WebAssembly, at most one table is allowed in a module. Consequently, the only valid is .
class=""> 2.5.8. Data Segments
The initial contents of a memory are zero bytes. The component of a module defines a vector of
vector of bytes. expression.Note
In the current version of WebAssembly, at most one memory is allowed in a module. Consequently, the only valid is .
class="">class=""> 2.5.9. Start Function
The component of a module optionally declares class=""> <-ref">function index of a start function that is automatically invoked when the module is instantiated, after tables and memories have been initialized.
2.5.10. Exports
The component of a module defines a set of
instantiated. name. Exportable definitions are functions, tables, memories, and globals, which are referenced through a respective descriptor. Note
In the current version of WebAssembly, only immutable globals may be exported.
2.5.10.1. Conventions
The following auxiliary notation is defined for sequences of exports, filtering out indices of a specific kind in an order-preserving fashion:
-
2.5.11. Imports
The component of a module defines a set of
<.html#exec-instantiation">instantiation. name space, consisting of a name and a unique , tables, memories, and globals. Each import is specified by a descriptor with a respective type that a definition provided during instantiation is required to match.functions Every import defines an index in the respective index space. In each index space, the indices of imports go before the first index of any definition contained in the module itself.
Note
In the current version of WebAssembly, only immutable globals may be imported.
3. Validation
3.1. Conventions
Validation checks that a WebAssembly module is well-formed. Only valid modules can be instantiated.
Validity is defined by a type system over the abstract syntax of a module and its contents. For each piece of abstract syntax, there is a typing rule that specifies the constraints that apply to it. All rules are given in two equivalent forms:
- In prose, describing the meaning in intuitive form.
- In formal notation, describing the rule in mathematical form. [1]
Note
The prose and formal rules are equivalent, so that understanding of the formal notation is not required to read this specification. The formalism offers a more concise description in notation that is used widely in programming languages semantics and is readily amenable to mathematical proof.
In both cases, the rules are formulated in a declarative manner. That is, they only formulate the constraints, they do not define an algorithm. The skeleton of a sound and complete algorithm for type-checking instruction sequences according to this specification is provided in the appendix.
3.1.1. Contexts
Validity of an individual definition is specified relative to a context, which collects relevant information about the surrounding module and the definitions in scope:
- Types: the list of types defined in the current module.
- Functions: the list of functions declared in the current module, represented by their function type.
- Tables: the list of tables declared in the current module, represented by their table type.
- Memories: the list of memories declared in the current module, represented by their memory type.
- Globals: the list of globals declared in the current module, represented by their global type.
- Locals: the list of locals declared in the current function (including parameters), represented by their value type.
- Labels: the stack of labels accessible from the current position, represented by their result type.
- Return: the return type of the current function, represented as a result type.
In other words, a context contains a sequence of suitable types for each index space, describing each defined entry in that space. Locals, labels and return type are only used for validating instructions in function bodies, and are left empty elsewhere. The label stack is the only part of the context that changes as validation of an instruction sequence proceeds.
It is convenient to define contexts as records with abstract syntax:
< The fields of a context are not defined as vectors, since their lengths are not bounded by the maximum vector size.
In addition to field access the following notation is adopted for manipulating contexts:
denotes the same context as but with the elemclass=""> <> component sequence. Note This notation is defined to prepend not append. It is only used in situations where the original is either empty or is
label index space is indexed relatively, that is, in reverse order of addition. 3.1.2. Prose Notation
Validation is specified by stylised rules for each relevant part of the abstract syntax. The rules not only state constraints defining when a phrase is valid, they also classify it with a type. The following conventions are adopted in stating these rules.
-
A phrase is said to be “valid with type ” if and only if all constraints eclass="">
<> depends on what is. -
The rules implicitly assume a given context .
-
In some places, this context is locally extendclass="">
with additional entries. The formulation “Under context , … < is adopted to express that the following statement must apply under class="">
3.1.3. Formal Notation
Note
This section gives a brief explanation of the notation for specifying typing rules formally. For the interested reader, a more thorough introduction can be found in respective text books. [2]
The proposition that a phrase has a respective type is written class="">
. To expreclass=""> < complete form is a judgement holds under the assumptions encodeclass=""> . The fclass="">
deduction rules. Every rule has the following general form: axioms whose conclusion holds unconditionally. The conclusion always is a judgment , and there is one respective rule for each relevant construct Note For example, the typing rule for the
can be typed as follows:class=""> local index exists in the context. The instruction produces a value of its respective type does not exist then the premise does noclass=""> structured instruction requires a recursive rule, where the premise is itself a typing judgement:instruction is only valid whenclass=""> . If so, then thewith the additional label information for the premise. [1] The semantics is derived from the following article: Andreas Haas, Andreas Rossberg, Derek Schuff, Ben Titzer, Dan Gohman, Luke Wagner, Alon Zakai, JF Bastien, Michael Holman. Bringing the Web up to Speed with WebAssembly. Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2017). ACM 2017. [2] For example: Benjamin Pierce. Types and Programming Languages. The MIT Press 2002 3.2. Types
Most types are universally valid. However, restrictions apply to function types as well as the limits of table types and memory types, which must be checked during validation.
3.2.1. Limits
Limits must have meaningful bounds.
3.2.1.1. <">
- If the maximum is not empty, then its value must not be smaller than .
- Then the limit is valid.
< 3.2.2. Function Types
Function types may not specify more than one result.
3.2.3. Table Types
3.2.3.1.
- The limits must be valid
<3.2.4. Memory Types
3.2.4.1.
must be valid - The global type is valid.
<
3.3. Instructions
Instructions are classified by function types that describe how they manipulate the
that an instruction pops off and the provided output stack with result values of types that it pushes class=""> . Such a sequence has aNote
class="">has type if the accumulative effect of executing the instructions is consuming vclass=""> . For some inclass="">
< are called polymorphic. Two degrees of polymorphism can be distinguished: - value-polymorphic:
the value type of one or several individual operands is unconstrained.
That is the case for all
<>parametric instructions like and
of the instruction is unconstrained. That is the case for all that perform an unconditional control transfer, such as , Note
For example, the instruction is valid with type
, for any possible being instantiated to , reclass=""> instruction that would make the sequence well-typed. 3.3.1. Numeric Instructions
3.3.1.1.
. <2" id="-tmathsfhref-syntax-instructionshtmlsyntax-unopmathitunop">3.3.1.2. . <.3" id="-tmathsfhref-syntax-instructionshtmlsyntax-binopmathitbinop">3.3.1.3. . <1.4" id="-tmathsfhref-syntax-instructionshtmlsyntax-testopmathittestop">3.3.1.4. . class=""> <.5" id="-tmathsfhref-syntax-instructionshtmlsyntax-relopmathitrelop">3.3.1.5. . class=""> < id="-t_2mathsfhref-syntax-instructionshtmlsyntax-cvtopmathitcvtop-t_1">3.3.1.6. . 3.3.2. Parametric Instructions
3.3.2.1.
, for any <" id="-href-syntax-instructionshtmlsyntax-instr-parametricmathsfselect">3.3.2.2. , for any and < 3.3.3. Variable Instructions
3.3.3.1.
must be defined in the context. - Let bclass=""> <="std std-ref">value type
. - Then the instruction is valid with type <
<.3.2" id="-href-syntax-instructionshtmlsyntax-instr-variablemathsfset_localx">3.3.3.2. must be defined in the context. - Let bclass=""> <="std std-ref">value type
. - Then the instruction is valid with type <
- value-polymorphic:
the value type of one or several individual operands is unconstrained.
That is the case for all
<>parametric instructions like and
<3.2.5. Global Types
3.2.5.1. <
2.1.3. Vectors
Vectors are bounded sequences of the form (or ),
where the can either beclass="">
WebAssembly programs operate on primitive numeric values.
Moreover, in the definition of programs, immutable sequences of values occur to represent more complex data, such as text strings or other vectors. The simplest form of value are raw uninterpreted bytes.
In the abstract syntax they are represented as hexadecimal literals. Different classes of integers with different value ranges are distinguished by their bit width and by whether they are unsigned or signed. Note The main integer types occurring in this specification are , class="">
Floating-point data represents 32 or 64 bit values that correspond to the respective binary formats of the IEEE 754-2008 standard (Section 3.3). Every value has a sign and a magnitude.
Magnitudes can either be expressed as normal numbers of the form , where is the exponent and
Poclass="">
A canonical NaN is a floating-point value
In the abstract syntax, subnormals are distinguished by the leading 0 of the significand. The exponent of subnormals has the same value as the smallest possible exponent of a normal number. Only in the binary representation the exponent of a subnormal is encoded differently than the exponent of any normal number. Names are sequences of scalar code points as defined by Unicode (Section 2.4). Various entitites in WebAssembly are classified by types.
Types are checked during validation, instantiation, and possibly execution. Value types classify the individual values that WebAssembly code can compute with and the values that a variable accepts. The types and
Function types classify the signature of functions,
mapping a vector of parameters to a vector of results. In the current version of WebAssembly,
the length of the result type vector of a valid function type may be at most .
This restriction may be removed in future versions. Limits classify the size range of resizeable storage associated with memory types and table types. Memory types classify linear memories and their size range. Table types classify tables over elements of element types within a size range. The element type is the infinite union of all
Note In future versions of WebAssembly, additional element types may be introduced. Global types classify global variables, which hold a value and can either be mutable or immutable. External types classify imports and external values with their respective types. The following auxiliary notation is defined for sequences of external types.
It filters out entries of a specific kind in an order-preserving fashion:2.2. Values
2.2.1. Bytes
2.2.2. Integers
2.2.2.1. Conventions
2.2.3. Floating-Point
2.2.4. Names
2.3. Types
2.3.1. Value Types
2.3.1.1. Conventions
2.3.3. Function Types
2.3.4. Limits
2.3.5. Memory Types
2.3.6. Table Types
2.3.7. Global Types
2.3.8. External Types
